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(54) Over the air locking of user identity modules for mobile telephones 



(57) A mobile telephone network in which user iden- 
tify module (UIM) locking is activated automatically by 
the network via signalling over the base station to mobile 
telephone common air interface. The telephone network 
periodically or regularly queries the Internal Mobile 
Equipment Identity (IMEI)of the mobile telephone being 
used by subscribers on the system. If the I ME I of a mo- 
bile telephone is found on a 'stolen list* the network may 
then command the mobile station to activate UIM lock- 
ing by messaging to and from the mobile telephone over 
the air interface to activate the UIM locking function us- 
ing a transmitted bit pattern. 
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Description 

The present invention relates to a mobile terminal 
for telecommunications, for example a portable tele- 
phone, and to a communications network making use 
of such terminals. More particularly, the present inven- 
tion relates to portable telephones employing user iden- 
tity modules (UIMs). 

Portable telephone systems are known that contain 
a subscriber or user identity feature wherein the tele- 
phone can.be manually locked to a user identity module 
(UIM). 

European Patent application number 93302420.0, 
publication number EP 0,562,890 A1 to Green entitled 
"Mobile Communication Network with Remote Updating 
of Subscriber Identity Modules in Mobile Terminals", 
filed 29 March, 1993 discloses a communications net- 
work that has a switching network including a mobile 
switching center which communicates, by radio tele- 
phone, with a mobile telephone. The mobile equipment 
contains a subscriber identity module which stores data 
for controlling the operation of, and the facilities availa- 
ble to the user, of the mobile equipment. The switching 
network transmits updating signals to the mobile equip- 
ment which alter the data stored in the subscriber iden- 
tity module and hence alter the operation on facilities 
available. 

At present, mobile telephones, particularly those 
based on the Groupe Speciale Mobile (GSM) Stand- 
ards, contain an electronic module, previously known as 
a subscriber identity module or SIM and which is now 
called a user identity module (UIM). The Ul M stores data 
to be used by the mobile telephone, also referred to 
herein as a mobile terminal (MT). The UIM is pre-con- 
figured to contain a unique identifier for a particular user, 
and may also contain appropriate authentication func- 
tions. The UIM is also able to store temporary data such 
as paging messages and a telephone number directory. 

In current GSM based systems, the subscriber 
identity is not related to the mobile terminal (MT). This 
is accomplished by the use of the UIM. The UIM is a 
module, or smart card, that installs in the phone and has 
a unique user identity information. 

GSM based systems allow a user to insert his UIM 
card into any mobile terminal and be recognized by the 
GSM network via information on the UIM rather than in- 
formation associated with the particular terminal in use. 
In this system the mobile is identifiable by an IMEI (In- 
ternational Mobile Equipment Identity); however, que- 
ries to check this information are 'expensive' in terms of 
processing and are not normally verified on a per call 
basis. 

These factors have been exploited by thieves who 
have developed an extensive 'black market' in terminals 
using GSM based interfaces and has resulted in hun- 
dreds of thousands of mobile terminals being stolen 
each year. 

Known lock functions commonly have a four to eight 



digit pin code and, if activated, the code must be entered 
each time the mobile terminal is powered up before any 
operations can be performed. 

Also, mobile terminals also provide a UIM lock de- 
s signed to prevent the mobile station from accepting un- 
authorized UIMs without a master password. If activat- 
ed, the mobile station will only accept previously author- 
ized UIMs. 

According to a first aspect of the present invention 

10 there is provided a mobile communications network 
comprising at least one central base switching network 
and a plurality of remote mobile terminals containing cir- 
cuits for transmitting and receiving electronic signals, 
each of said remote mobile terminals including a user 

15 identity module (UIM) containing personalized user data 
for controlling the transmission of signals therefrom, 
wherein said central base switching network includes 
means for transmitting data signals to a selected remote 
mobile terminal for selectively locking said selected re- 

20 mote mobile terminal to said included UIM and said in- 
cluded UIM to said selected remote mobile terminal, 
thereby selectively preventing operation of said select- 
ed remote mobile terminal with any other of said UIMs 
and operation of said included UIM with any other of said 

25 remote mobile terminals. 

According to a second aspect of the present inven- 
tion there is provided a method for locking a selected 
remote mobile terminal of a mobile communications net- 
work having at least one central base switching network 

30 and a plurality of remote mobile terminals containing cir- 
cuits for transmitting and receiving electronic signals, 
each of said remote mobile terminals including a user 
identity module (UIM) containing personalized user data 
for controlling the transmission of signals therefrom, 

35 comprising the steps of step 1 . transmitting data signals 
from said central base switching network to a UIM of a 
selected remote mobile terminal and step 2. receiving 
said data signals transmitted from said central base 
switching ntwork and selectively locking said selected 

40 mobile remote terminal to said included UIM, and said 
included UIM to said selected remote mobile terminal, 
thereby preventing operation of said selected remote 
mobile terminal with any other UIMs and operation of 
said included UIM with any other of said remote mobile 

45 terminals. 

Embodiments of the present invention may reduce 
the value of a stolen mobile terminal, once detected, by 
"locking" the mobile terminal to the UIM card in use in 
the mobile terminal at the time of detection, if any. Lock- 

50 ing the mobile terminal to a specific UIM means that the 
mobile terminal cannot be used with any other UIM and 
thus diminishes its re-sale value. Additionally, this pro- 
cedure is coupled with information collection about the 
UIM being used in the stolen mobile terminal for follow- 

55 up by the proper authorities to recover the mobile 
terminal . 

Exemplary embodiments in accordance with the 
present invention may provide a mobile telephone sys- 



2 



3 EP 0 757 

« • 

* 

tem wherein UIM locking and unlocking is activated au- 
tomatically by the network via signalling over the BTS 
to mobile station common air interface. 

Exemplary embodiments in accordance with the 
present invention may provide a mobile telephone sys- 5 
tem that allows for the option of locking the UIM to the 
mobile telephone such that the UIM can only be used 
with the specific associated mobile telephone. 

Exemplary embodiments in accordance with the 
present invention may provide a mobile telephone sys- 10 
tem that allows for the option of locking the mobile tele- 
phone to the UIM such that the mobile telephone can 
only be used with the specific UIM. 

Embodiments of the invention will now be de- 
scribed, by way of example, with reference to the ac- is 
companying drawings, in which: 

Fig. 1 is a schematic block diagram illustrating one 
embodiment of a communications network of the 
present invention; 20 

Fig. 2 shows a flow chart of the network logic, MSC 
30 of Fig. 1 , for the processing of messages in ac- 
cordance with a method of the present invention; 

25 

Fig. 3 shows a flow chart of the mobile terminal log- 
ic, MT 10 of Fig. 1 , for the processing of messages 
in accordance with a method of the present inven- 
tion; 

30 

Fig. 4 shows a flow chart of the user interface mod- 
ule logic, Ul M 20 of Fig. 1 , for the processing of mes- 
sages; 

Figs. 5a and 5b show the structure of messages 35 
which may be used in embodiments in accordance 
with the invention; and 

Fig. 6 shows a flow chart for initialization logic re- 
quired in the UIM 20 of Fig. 1 to carry out the UIM- *o 
I MEI locking in an embodiment of the present inven- 
tion. 

Currently, GSM mobile terminals are easily reused 
after being stolen simply by inserting a valid UIM card if 45 
the legitimate owner forgot or neglected to 'lock' his mo- 
bile to his UIM. Additionally, since rental units would nor- 
mally not locked to a specific UIM card, these mobile 
terminals are particularly vulnerable to theft. Due to 
these facts there is a flourishing market in stolen GSM so 
mobile terminals. In accordance with embodiments of 
the present invention there is shown a mechanism and 
method by which a mobile terminal which has been de- 
termined to be stolen can be locked to the UIM inserted 
in the unit and thereby be made less valuable in terms 55 
of re-sale. 

A mobile terminal (MT) in accordance with the 
present invention is locked to the UIM by an over-the- 



502 A2 4 

air command. Additionally, embodiments of the present 
invention show a system wherein a UIM inserted in a 
mobile terminal can be locked to the mobile terminal's 
IMEI, thereby making the UIM usable only in the mobile 
terminal it is locked to. 

More particularly the telephone network periodically 
or regularly queries the I ME I of the mobile terminal being 
used by subscribers on the system. If the IMEI of a mo- 
bile terminal is found on a 'stolen list' the network may 
then command the mobile station to activate UIM lock- 
ing by messaging to and from the mobile terminal over 
the air interface to activate the UIM locking function us- 
ing a transmitted bit pattern. 

A communications network typically includes a mo- 
bile switching center (MSC) that communicates, such 
as by radio telephony, with mobile terminals (MT) such 
as a mobile telephone. The mobile terminal contains a 
subscriber, or user identity module that stores data for 
controlling the operation of and the facilities available to 
the user of the mobile terminal. 

In accordance with an aspect of the present inven- 
tion, the switching network transmits updating signals to 
the mobile terminal that alters the data and security sta- 
tus of the mobile terminal and/or the security status of 
the user identity module. 

Referring to Fig. 1, a communications network is 
shown including a mobile terminal (MT) 10 such as a 
mobile telephone and a switching network 8 containing 
mobile switching (MSC) center 30, a number of base 
station controllers (BSC) 40 for different cell sites in 
which the mobile terminal 10 can operate an equipment 
identity register (EIR) 60 is connected to a common 
equipment identity register (CEIR) 80 which may be 
connected to other equipment identity registers 60-1, 
60-2, 60-N associated with other switching networks 
and their associated mobile terminals. An operation 
sub-system (OSS) 70 may be provided to update the 
equipment identity register 60. Communication over the 
air to and from mobile terminals such as mobile terminal 
1 0 is carried out via a base station transceiver unit (BTS) 
50. 

Each mobile terminal in the communications net- 
work such as mobile terminal 10 includes a user identity 
module (UIM) 20 that stores pre-programmed data 
unique to a particular user and an international mobile 
equipment identity unit (IMEI) 15. Each international 
mobile equipment identity 15 is unique to its mobile ter- 
minal 10 and is used to identify the mobile terminal 10 
to the mobile switching center 30. 

In Fig. 1, normal communication occurs between 
the communications network from the MSC 30 to a mo- 
bile telephone or other mobile terminal MT 10 via one 
of many base station controllers BSC 40 over one of its 
associated base transceiver systems BTS 50. 

The MT 10 contains a user identity module UIM 20 
which stores a unique identifier of a specific user as well 
as any available authentication functions for that user. 
The MT 10 also contains a unique international mobile 
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equipment identity IMEI 15. 

The MSC 30 contains or has communication chan- 
nels to access the home location register HLR 35 for a 
specific user. The HLR 35 contains a functional subdi- 
vision known as the authentication center AuC 36 which 
manages the security data used for the authentication 
of users. Together, the AuC 36 functions of the HLR 35 
and the corresponding authentication functions in the 
UIM 20 provide a relatively secure and robust means to 
validate or authenticate a user and thus prevent various 
types of fraudulent use. 

The MSC 30 has communications channels to ac- 
cess an equipment identity register EIR 60 which is a 
database which contains information regarding the va- 
lidity and status of mobile equipment MT 10 via their in- 
ternational mobile equipment identifiers IME1 15 known 
to the communication network. The EIR 60 contains 
three 'lists'. One is the 'white list' which includes the 
range of valid type-approved mobile equipment MT 10. 
Another is the 'black list 1 which includes the list of IMEI 
15 which have been reported as either stolen or having 
severe malfunctions. The third list, 'grey list" is an inter- 
mediate between 'white' and 'black' which includes sus- 
pect units before authorities confirm black listing. 

The steps of a process in accordance with the 
present invention are shown in the blocks of Fig. 2. At 
the start of communications between the MT 10 and the 
MSC 30 various obligatory messaging sequences are 
exchanged which are common knowledgeto one skilled 
in the art. After this conventional messaging the MSC 
30 is required to obtain the IMEI 1 5 of the MT 10 as in- 
dicated in Fig. 2 block 300. In conventional systems this 
is accomplished by the transmission of IDENTITY RE- 
QUEST Message to the MT 10. The conventional MT 
10 responds with IDENTITY RESPONSE Message 
which contains the IMEI 15. One of the features in ac- 
cordance with the present invention is the optimization 
of this messaging exchange by including the IMEI 15 
information in the conventional obligatory messages 
noted earlier. Specifically in a preferred embodiment of 
this invention the IME1 1 5 information is packaged in the 
LOCATION UPDATING REQUEST message from the 
MT10. 

The format and structure of the LOCATION UPDAT- 
ING REQUEST in conventional systems may only carry 
the IMEI if the MT 10 does not contain an UIM 20 or the 
UIM 20 is considered invalid for some reason. It is the 
subject of an optimization aspect of this invention to al- 
ways include the IMEI in the LOCATION UPDATING 
REQUEST whether or not a TMSI or IMSI is also includ- 
ed in this message. I n those cases where a TMSI or I MSI 
is also included in the LOCATION UPDATING RE- 
QUEST, the message shall contain two MOBILE IDEN- 
TITY information element one for TMSI or IMSI and one 
for IMEI. In those cases where the LOCATION UPDAT- 
ING REQUEST contains only the IMEI the message 
shall be identical to the conventional LOCATION UP- 
DATING REQUEST used in today's systems. 
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Regardless of how the IME1 1 5 is obtained, via MSC 
30 explicit IDENTITY REQUEST sequence or automat- 
ically via a preferred enhancement of the LOCATION 
UPDATING REQUEST or other conventional obligatory 

5 message, the MSC 30 queries the EIR 60 at block 305 
of Fig. 2 to determine the status of the IME1 15 reported 
from the MT 10. If the EIR60 indicates that the IME1 15 
is included in the 'black list' as a stolen mobile or as a 
unit with severe malfunction at block 310 control flows 

10 to block 311 where the MSC 30 determines if the MT- 
UIM Locking function is enabled. If the EIR 60 query in- 
dicated that the mobile terminal was not stolen or 'black 
listed' in block 310, control branches to block 335 and 
the process is finished. 

15 The MT-UIM Locking function will normally be ena- 
bled, but may be disabled for a particular MSC 30 if its 
operator so desires. If the function is enabled in block 
311 branching at block 311 passes to block 315. If MT- 
UIM Locking function is disabled branching at block 311 

20 passes to block 320. 

When control is passed to block 315 the MSC 30 
constructs a SECURITY REQUEST MESSAGE indicat- 
ing an MT-UIM LOCK command (Fig. 5a) and transmits 
this message via the BSC 40 and BTS 50 units in com- 

25 munication with the MT 10 illustrated in Fig. 1 . In a pre- 
ferred embodiment of the invention all SECURITY RE- 
QUEST messages are transmitted inciphered mode. 

The SECURITY REQUEST MESSAGE indicating 
MT-UIM LOCK command contains a RAND and SRES 

30 pair provided via the AuC 36 function of the HLR 35 as- 
sociated with the user UIM 20 in order to provide the MT 
. 10 with a means to ensure that the command is valid 
and not the result of unauthorized mischief or 'hacking'. 
Control flow from block 315 continues to block 316. In 

35 block 31 6 the MSC 30 is expecting a response from the 
MTI0. 

Fig. 3 outlines a mobile equipment logic MT 10 as- 
sociated with an aspect of the invention. When a mes- 
sage is received from the MSC 20, the MT 10 must de- 

40 termine if the message received represents a command 
to activate one of the newly defined LOCKs step 100. 
First check preferred is identified in step 105 as the 
check to see if the message is a SECURITY REQUEST 
MESSAGE INDICATING MT-UIM lock. If the message 

45 contains such a command, control flow branches form 
105 to step 120. If the message is not a MT-UIM LOCK, 
control flow branches from step 105 to step 110. 

Mobile equipment MT 1 0 processing from steps 110 
onwards will be discussed following the MSC 30 logic 

so associated with UIM-IMEI locking step 325 of Fig. 2. 

In step 1 20 of Fig. 3 the MT 1 0 must verify that the 
« message received is authorized. This is done by utilizing 
conventional authentication procedures in the UIM 20 
combined with new procedures in the MT 10 to execute 

55 the function. As noted in Fig. 5a, the MT-UIM LOCK 
message contains the RAND from the AuC 36, which is 
well known to one skilled in the art. In order to harden 
this procedure, the preferred embodiment of this inven- 
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tion willplace additional requirement on the RAND to 
protect against hacking. These requirements should be 
well considered and specific to a particular implemen- 
tation. The preferred method of hardening recommend- 
ed is to have the MT 1 0 construct an AUTHENTICATION 5 
REQUEST with a randomly chosen RAND and transmit 
this request to the MSC 30. The MSC 30 would then 
send the RAND received from the MT 10 to the appro- 
priate HLR 35 AuC 36 function and receive the correct 
SRES response. The MSC 30 would then construct an 10 
AUTHENTICATION RESPONSE message containing 
said SRES and transmit to the MT 10. The MT 10 would 
then compare the SRES received in the AUTHENTICA- 
TION RESPONSE from the MSC 30 to an SRES that 
UIM 20 calculated using the RAND originally sent to the *s 
MSC 30 in the AUTHENTICATION REQUEST mes- 
sage. If these two SRES values match, the SECURITY 
REQUEST is considered authentic. This method re- 
quires the MSC 30 and AuC 36 modified to support the 
messaging exchanges noted which are readily under- 20 
stood by one skilled in the art. Another example, of hard- 
ening considered could be to maintain a list of sufficient 
length of previously received RAND and checking the 
RAND received in the message against this list. If the 
. RAND is found in the list maintained, and one considers 25 
the probability of such a match unlikely the message 
may be discarded and control flow branches to step 1 31 . 
This type of procedure may be combined with other pro- 
cedures such as monitoring the frequency that various 
messages containing RAND are received; however, 30 
specifically identifying any method of additional harden- 
ing would only serve to provide 'hackers' with informa- 
tion which they should be denied. If the RAND passes 
the recommended hardening techniques chosen for the 
particular MT 10 implementation, the MT 10 proceeds 35 
with authentication process. The RAND is sent to the 
UIM 20 via conventional means and the UIM 20 returns 
an SRES value calculated in the conventional fashion 
by UIM 20 authentication logic. In step 130 the MT 10 
then compares the SRES received in the MT-UIM LOCK 40 
messages from MSC 30 to the SRES calculated by the 
UIM 20. If the two SRES values are identical, MT-UIM 
LOCK command is considered authentic and authorized 
and control flow branches from step 130 to step 140. If 
authentication fails in step 1 30, control flow branches to 45 
step 1 31 . 

In step 140 the MT 10 executes internal UIM locking 
procedures that modify the MT 10 processing to only 
accept the UIM 20 card that is currently installed in the 
MT 10 UIM locking procedures are unique to the hard- so 
ware and software design of the MT 10 in question are 
must be closely guarded to ensure the security of this 
function against 'hacking* or other fraud. UIM locking 
procedures for a specific MT 10 design are well known 
to those skilled in the art and application to a specific 55 
MT 10 design but never disclosed due to the security 
risk of such disclosure. Control flows from step 140 to 
step 141 where the MT 10 determines if the MT-UIM 
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LOCKING procedure was successful, if so control flow 
branches to step 1 42 and if not to step 1 31 . 

In step 1 42 the MT 1 0 has verified that is has locked 
to the UIM 20 in question and therefore constructs a SE- 
CURITY RESPONSE (Fig. 5b) indicating the MT-UIM 
LOCK was successful. This message is transmitted to 
the MSC 30. Control flow falls to step 1 50 and the proc- 
ess is finished. 

Step 131 constructs a SECURITY RESPONSE in- 
dicating the MT-UI M lock operation failed and the failure 
reason. This message is then transmitted to the MSC 
. 30 and indicates the.failure reason as either authentica- 
tion failure or other processing failure. Control flow then 
falls to step 150 and the process is finished. 

Having explored the control flow of MT 10, refer- 
ence is now made to Fig. 2 step 316 and where the dis- 
cussion regarding the MSC 30 control flow was left. The 
MSC 30, having received a response or timing out on a 
response from MT 1 0 has its control flows from step 31 6 
to step 317 where the MSC 30 stored the information 
regarding the results of the MT-UIM LOCK operation 
from the MT 10 for future reference by step 330. Then 
control flows from step 317 to step 320. 

In block 320 the MSC 30 determines whether UIM- 
IMEI Locking function is enabled. The conditions for de- 
termining if this function is enable will vary greatly de- 
pending on regulatory issues, operator preference and 
other factors therefore, a 'normal' mode of operation is 
not expected for this function, it is completely at operator 
preference; however, if the function is enabled control 
flow branches from block 320 to block 325. If the function 
is disabled control flow branches from block 320 to block 
330. 

In block 325, the MSC 30 constructs a SECURITY 
REQUEST indicating a UIM-IMEI LOCK command and 
transmits this message to the MT 10. Like the MT-UIM 
LOCK command, the UIM-IMEI LOCK command con- 
tains a RAND and SRES pair from the AuC 36 function 
associated with the UIM 20 as a means to authenticate 
the operation. Control flow from block 325 proceeds to 
block 330. 

The MSC 30 control flows from step 325 to step 326 
where the MSC 30 effectively waits for a response or 
will timeout waiting on a response for MT 10, thus will 
now focus on the MT 10 processing noted in Fig. 3 

As noted previously, when the MT 10 receives a 
message from MSC 30, the control flows through step 
100 to 105. If in step 105 the message received did not 
indicate an MT-UIM lock command control flows from 
step 105 to step 110. 

Step 1 1 0 test the contents of the received message 
to determine if it contains a UIM-IMEI LOCK command. 
If so, control branches from step 110 to step 125. If not, 
control flow branches from step 110 to step 115. 

Step 115 represents the processing of other com- 
mands received from MSC 30 which are not of interest 
and therefore we can consider processing in this em- 
bodiment of the invention. 
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Step 1 25 is responsible for ensuring the authenticity 
of the received UIM-IMEI LOCK command. As indicated 
in Fig. 5a, the SECURITY REQUEST indicating UIM- 
IMEI LOCK command contains the RAND and SRES 
calculated for the UIM 20 in question by the AuC 36 as- 
sociated with this UIM 20. As noted in the discussion of 
Fig. 3, step 120, preferred embodiments will have addi- 
tional hardening requirements placed on the RAND by 
the MT 10. These hardening requirement may be inten- 
tionally different from those chosen in step 120 or iden- 
tical depending on implementors decision. If the hard- 
ened RAND requirements do not pass the MT 10 de- 
clares the command invalid in step 135 and branches 
to step 136. Otherwise the UIM-IMEI LOCK command 
is transferred from the MT 10 to the UIM 20 complete 
with both the RAND and the SRES contained in the mes- 
sage received from the MSC 30 for further processing. 
Control flow then proceeds from step 1 35 to step 1 45. 

Instep 145 the MT 10 transmits the UIM-IMEI LOCk 
message to the UIM 20 and waits for the results of the 
operation or timeout. 

Fig. 4 indicates the control flow within the UIM 20 
for the processing of the UIM-IMEI LOCK command. 
The process is initiated by the receipt of the UIM-IMEI 
LOCK command from the MT 1 0 step 1 45 which results 
in step 200 of Fig. 4 UIM 20. Control flows from step 200 
to step 205 where the UIM extracts the RAND contained 
in the UIM-IMEI LOCK message and calculates SRES 
in the conventional fashion. Once the UIM 20 has cal- 
culated SRES in step 205 control flows into step 210 
where the UIM 20 calculated SRES is compared to the 
SRES contained in the UIM-IMEI LOCK message from 
MSC 30. If the two SRES values are identical, control 
. branches from step 210 to step 215. If the two SRES 
values are not identical, control branches from step 21 0 
to step 230. 

In step 21 5 the UIM 20 request the IME1 15 from the 
MT 10. The IMEI 15 value is stored in the UIM 20 for 
future reference in every initialization cycle, etc. Control 
flows from step 21 5 step 220 where success of step 21 5 
is tested. If the operation completed successfully, con- 
trol flows from step 220 to step 225. If not, control 
branches from step 220 to step 230. 

Step 225 stores the fact that the UIM is now suc- 
cessfully locked to a specific IME1 15 by storing an indi- 
cator of this fact on the UIM 20. Additionally, the UIM 20 
indicates to the MT 10 that the UIM-IMEI LOCK com- 
mand has been successfully executed. Control flows 
from step 225 to step 235 and the process is finished. 

Step 230 sends an indication to the MT 10 that the 
UIM-IMEI LOCK operation in step 145 (or timeout) and 
proceeds to step 146 where if the operation was suc- 
cessful, MT 10 control branches from step 146 to step 
147. If not, control branches from step 146 to step 1 36. 

In step 147 the MT 10 constructs a SECURITY RE- 
SPONSE indicating the UIM-IMEI LOCK was success- 
ful and transmits this message to the MSC 30. Control 
in the MT 10 then flows from step 147 to step 150 and 
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the MT 10 process is complete. 

In step 136 the MT 10 constructs a SECURITY RE- 
SPONSE indicating UIM-IMEI LOCK failure and trans- 
mits this message to MSC 30. Control in MT 10 then 
5 flows from step 1 36 to step 1 50 and the MT 1 0 process 
is complete. 

In step 136 the MT 1 0 constructs a SECURITY RE- 
SPONSE indicating UIM-IMEI LOCK failure and trans- 
mits this message to MSC 30. Control in MT 10 then 
io flows from step 1 36 to step 1 50 and the MT 1 0 process 
is complete. 

Referring now to Fig. 2, control flow from step 326 
proceeds to step 327 as the MSC 30 has received a re- 
sponse from the MT 10. In step 327 MSC 30 stores the 

'5 results reported from the MT 10 for reference in step 
330. The control then flows from step 327 to step 330. 

Block 330 handles the processing of administrative 
reports. In a preferred embodiment, these reports will 
contain the IMEI 1 5 of the MT 10 in question, the status 

20 associated with the IME1 1 5 from the El R 60, information 
regarding the user associated with the UIM 20 contained 
in the MT 10 and the action take by the MSC 30 which, 
depending on the branches taken, may include: Report 
Only, MTA-UIM LOCK (success/failure/not attempted), 

2S UIM-IMEI LOCK (success/failure/not attempted) as well 
as the results of MT 10 locking operations if applicable. 
These reports would eventually forwarded to the proper 
authorities for possible criminal investigations, etc. 
In step 605 the UIM 20 request the IMEI 15 of the 

30 current MT 10. Control flows from step 605 to 610 where 
the success of the IMEI query operation of step 605 is 
checked. If the IME1 15 of the current MT10 is received, 
control branches from step 610 to step 615. If not, con- 
trol branches from step 605 to step 625. 

35 step 615 compares the IMEI 15 received from the 
current MT 10 to the IMEI 15 stored on the UIM 20 in 
step 215 of Fig. 4. If the two IMEI values are identical, 
control flow branches from step 620 to step 699 where 
conventional processing continues and the process is 

40 finished with respect to the current invention. If the two 
IMEI values are not identical, control branches from step 
620 to step 625. 

In step 625 the UIM 20 indicates that the initializa- 
tion process is halted to the MT 1 0 because the UIM 20 

45 is currently locked to an IMEI 15 that is different from 
the IMEI 15 received from the current MT 10. Control 
then flows from step 625 to step 630 and the process is 
finished. 

Fig. 5a is a preferred embodiment of the MSC 30 to 
so MT 10 SECURITY REQUEST message. The message 
is new; however, several components of the message 
are conventionally used in the existing system. The new 
information elements are SECURITY REQUEST MES- 
SAGE TYPE which is an eight bit value which will 
55 uniquely identify this message type within the MOBILI- 
TY MANAGEMENT set of messages. This value is as- 
signed by standardization bodies any value is accepta- 
ble as long as it is unique in the SECURITY MESSAGE 
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range of'Mobility management message types. The next 
new information element is TYPE OF SECURITY RE- 
QUEST The preferred length of this information ele- 
ment is eight bits. One bit is reserved. One bit is used 
to indicate the lock state requested where 0 signifies 
'UNLOCK' and 1 signifies 'LOCK 1 . One bit to indicate 
MT-UIM lock and one bit to indicate the UIM-IMEI lock. 
The rest reserved. The MT-UIM and UIM-IMEI bits could 
be used as a bit mask such that the MSC 30 could in- 
struct the MT 10 to lock action or unlock both locks via 
one message; however, the preferred embodiment is 
only one lock per message for simplicity. Numerous oth- 
er formats and structures could be employed to realize 
this embodiment of the invention. 

Fig. 5b is a preferred embodiment of the MT 10 to 
MSC 30 SECURITY RESPONSE. As noted in Fig. 5a 
several of the information elements are conventional. 
The SECURITY RESPONSE MESSAGE TYPE is an 
eight bit value which will uniquely identify this message 
type within the MOBILITY MANAGEMENT set of mes- 
sages. This value is assigned by standardization bodies 
any value is acceptable as long as it is unique in the 
SECURITY MESSAGE range of Mobility management 
message types. The TYPE OF SECURITY REQUEST 
is as described in Fig. 5a. For simplicity, the preferred 
embodiment is only one lock action per message; how- 
ever, if there were more than one lock identifier set in 
the SECURITY RESPONSE message, there would be 
multiple RESULT CODE information elements, one for 
each lock identified set (i.e. value 1). The RESULT 
CODE would map such that the first RESULT CODE IEI 
corresponds to the lock identified in the least significant 
bit of the locking bit map, etc. Value of "0" indicates that 
the operation was successful. The RESULT CODE val- 
ue of "1" indicates failure because SRES calculated by 
UIM 20 did not.match the SRES in the SECURITY RE- 
QUEST The binary result code of MO" indicates the op- 
eration failed due to a time out failure of the preferred 
hardening technique of sending the authentication re- 
quest message to the MSC 30. The binary result code 
of.'ir indicates the SRES of the authentication re- 
sponse from MSC 30 was incorrect. All other values rep- 
resent various types of failures whose meaning is only 
known to the manufacturer of the MT 10 involved. Nu- 
merous other formats and structures could be employed 
to realize this embodiment of the invention. 

Fig. 6 illustrates UIM 20 logic which must be insert- 
ed before conventional logic in order to realize the UIM- 
IMEI LOCK invention. In step 600, as soon as possible 
in the conventional processing of the UIM 20 and before 
UIM 20 initialization is complete, the UIM 20 checks its 
control structures to determine if the Ul M 20 is currently 
locked to a specific I ME I 15 associated with a specific 
MT 1 0. If so, control branches from step 600 to step 605. 
If not, control flow branches from step 600 to step 699 
where conventional processing continues and the proc- 
ess is finished with respect to this embodiment of the 
invention. 
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Note that a similar figure for mobile equipment MT 
10 initialization processing could be provided; however, 
since MT 10 to UIM 20 locking currently exist via differ- 
ent activation methods this information is well known to 

5 those skilled in the art and is not described herein. 

Embodiments in accordance with the present inven- 
tion ideally support the unlocking of both the MT-UIM 
and UIM-IMEI functions via messages. To one skilled in 
the art, the format of the SECURITY REQUEST mes- 

10 sage supports this via the 'UNLOCK' bit discussed in 
Fig. 5a. The logic and control flows for the unlock oper- 
ations are obvious when considering Figs. 3 and 4. The 
logical unlock operation for MSC 30 is much the same 
as the lock operations except the triggers in Fig. 2, step 

is 310 may be the 'white listing' of a previously 'black listed' 
MT 10 or manual interaction via an operator's technician 
and various MSC 30 interfaces to force the transmission 
of the appropriate unlock command(s). A preferred em- 
bodiment supports both the 'batch' type process of 

20 'black listed' transition to 'white listed' and manual inter- 
vention. 

While embodiments of the invention have been dis- 
closed in detail, it should be understood by those skilled 
in the art-that various other modifications may be made 
25 to the illustrated embodiments without departing from 
the scope of the invention as described in the specifica- 
tion and defined in the appended claims; 

so Claims 

1. A mobile communications network comprising at 
least one central base switching network and a plu- 
rality of remote mobile terminals containing circuits 

35 for transmitting and receiving electronic signals, 
each of said remote mobile terminals including a us- 
er identity module (UIM) containing personalized 
user data for controlling the transmission of signals 
therefrom, 

40 wherein said central base switching network 

includes means for transmitting data signals to a se- 
lected remote mobile terminal for selectively locking 
said selected remote mobile terminal to said includ- 
ed UIM and said included UIM to said selected re- 

45 mote mobile terminal, thereby selectively prevent- 
ing operation of said selected remote mobile termi- 
nal with any other of said UIMs and operation of said 
included UIM with any other of said remote mobile 
terminals. 

so 

2. A mobile communications network according to 
claim 1 wherein said central base switching network 
includes means for transmitting data signals to a se- 
lected remote mobile terminal for locking said se- 

55 lected remote terminal to said included UIM, there- 
by preventing operation of said selected remote 
mobile terminal with any other of said UIMs. 
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3. A rhobile communications network according to 
claim 1 or claim 2 wherein said central base switch- 
ing network includes means for transmitting data 
signals to a selected remote mobile. terminal for 
locking said included UIM to said selected remote s 
terminal thereby preventing operation of said in- 
cluded UIM with any other of said remote mobile 
terminals. 

4. A mobile communications network according to 10 
claim 1 , claim 2 or claim 3 wherein each UIM in each 

of said remote mobile terminals includes a storage 
means for storing said personalized user data. 

5. A mobile communications network according to is 
claim 1 wherein each UIM in each of said remote 
mobile terminals includes means responsive to said 
data signals transmitted from said central base 
switching network for preventing operation of said 
remote mobile terminal with any other UIM when 20 
said transmitted data signal data is the same as said 
personalized user data stored in said UIM of said 
remote mobile terminal. 

6. A mobile communications network according to any 25 
preceding claim wherein said remote mobile termi- 
nals are cellular telephones. 

7. A mobile communications network according to any 
preceding claim wherein each of said remote mo- 30 
bile terminals include a unique international mobile 
equipment identity (IMEI). 

8. A mobile communications network according to any 
preceding claim wherein said central base switch- 3$ 
ing network includes a mobile switching network in- 
cludes a mobile switching center (MSC) connected 

to at least one base station control (BSC) and at 
least one base transceiver system (BTS) for trans- 
mitting said data signals to said selected remote *o 
mobile terminal. 

9. A mobile communications network according to 
claim 8 wherein said mobile switching center (MSC) 

. includes a home location register (HLR) having an 
authentication center (AUC), and wherein said mo- 
bile switching center (MSC) is connected to an 
equipment identity register (El R) containing data re- 
garding the validity and status of said mobile termi- 
nals, so 

10. A method for locking a selected remote mobile ter- 
minal of a mobile communications network having 
at least one central base switching network and a 
plurality of remote mobile terminals containing cir- 55 
cuits for transmitting and receiving electronic sig- 
nals, each of said remote mobile terminals including 

a user identity module (UIM) containing personal- 
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ized user data for controlling the transmission of sig- 
nals therefrom, comprising the steps of: 

step 1. transmitting data signals from said cen- 
tral base switching network to a UIM of a 
selected remote mobile terminal 

step 2. receiving said data signals transmitted 
from said central base switching network 
and selectively locking said selected mo- 
bile remote terminal to said included UIM, 
and said included Ul M to said selected re- 
mote mobile terminal, thereby preventing 
operation of said selected remote mobile 
terminal with any other UIMs and opera- 
tion of said included UIM with any other 
of said remote mobile terminals. 

11 . A method for locking a selected remote mobile ter- 
minal of a mobile communications network accord- 
ing to claim 10 wherein in said included UIM is 
locked to a said specific remote mobile terminal 

12. A method for locking a selected remote mobile ter- 
minal of a mobile communications network accord- 
ing to claim 10 or claim 11 wherein in step 2 said 
specific remote mobile terminal is locked to said in- 
cluded UIM. 

13. A method for locking a selected remote mobile ter- 
minal of a mobile communications network accord- 
ing to claim 10 or claim 11 step 2 includes compar- 
ing said personalized user data in said UIM to said 
received data signal from said central base switch- 
ing network, and locking said UIM and preventing 
operation of said selected remote module when 
said received data is the same as said personalized 
user data. 

14. A method for locking a selected remote terminal of 
a mobile communications network according to 
claim 13 that further includes authentication proce- 
dures contained in said UIM, and wherein step 2 
further includes comparing the results of said au- 
thentication procedures. 

15. A method for a selected remote mobile terminal of 
a mobile communications network according to any 
preceding claim wherein said step 1 includes the 
steps of obtaining the international mobile equip- 
ment identity (IMEI) of said selected mobile termi- 
nal, quering an equipment identity register (EIR) on 
the status of the international mobile equipment 
identity to determine if the selected remote mobile 
terminal is stolen, and transmitting a user identity 
module lock command to said selected remote mo- 
bile terminal. 
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16. A rrfethod for locking a selected remote mobile ter- 
minal of a mobile communications network accord- 
ing to claim 10 wherein said step 2 includes deter- 
mining if a received command transmitted from said 
central base switching network is a lock command, 5 
verifying the authenticity of said lock command, and 
executing a mobile terminal to user identity module 
lock. 

17. A method for locking a selected remote mobile ter- 10 
minal of a mobile communications network accord- 
ing to claim 1 6 wherein step 2 further includes send- 
ing an acknowledgment from said selected remote 
mobile terminal to said central base switching net- 
work that said selected remote mobile terminal has '5 
been locked. 
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